ci: build, smoke-test and publish the Xiongmai openipc-xm images - #14

• Add CI builds and 256 KiB NOR fit checks for XM510, XM530, and XM550.
• Gate releases on two protected-flash QEMU boots that verify saved environment persistence.
• Document the Xiongmai branch and add dispatch-only release and publishing paths.

graph TD
  R["Resolve revision"] --> B["Build NOR images"] --> S["QEMU smoke gate"] --> P["Publish images"] --> F[("Firmware latest")]
  Q["Build QEMU"] --> S
  S --> L[("Xiongmai release")]
  P --> W[("openipc.org records")]

Loading

The following are alternative approaches to this PR:

1. Parameterize the existing HiSilicon workflow

• ➕ Keeps common build, artifact, and publishing logic in one place.
• ➖ Adds family-specific branches to a mature workflow and increases regression risk for HiSilicon releases.

2. Pin the QEMU revision

• ➕ Makes the protected-flash smoke test reproducible across runs.
• ➖ Requires deliberate updates to receive machine-model fixes.

Recommendation: Keep the separate Xiongmai workflow: its three-SoC, two-boot gate differs enough to justify family isolation. Consider extracting shared publishing logic later if duplication grows, and pin a tested QEMU revision once the required WPS support is available.

Documentation (2) +71 / -0

CLAUDE.mdDocument Xiongmai branch and CI invariants +24/-0

Document Xiongmai branch and CI invariants

• Describes the openipc-xm branch, workflow triggers, two-boot smoke-test criterion, and release and publishing behavior.

CLAUDE.md

README.mdAdd Xiongmai build and workflow guidance +47/-0

Add Xiongmai build and workflow guidance

• Adds a workflow badge, branch listing, supported SoCs, build instructions, and CI and release guidance. Explains run-in-place NOR boot and the flash-protection behavior covered by smoke testing.

README.md

Other (1) +352 / -0

build-xm.ymlAdd gated Xiongmai build and publishing workflow +352/-0

Add gated Xiongmai build and publishing workflow

• Adds revision-pinned NOR builds for three SoCs with partition-fit checks, then smoke-tests each image twice in QEMU with flash protection enabled. Dispatch-only jobs upload gated artifacts to the Xiongmai release or OpenIPC/firmware and report the published build to openipc.org.

.github/workflows/build-xm.yml

Description

The flash-creation command pipes an infinite tr stream into head, which closes the pipe after 8
MiB and causes tr to exit with SIGPIPE. In the smoke step’s default Bash error-handling mode, that
nonzero pipeline result stops every SoC leg before the image is copied into flash or QEMU starts.

Code

.github/workflows/build-xm.yml[214]

+          tr '\0' '\377' < /dev/zero | head -c 8388608 > /tmp/flash.bin

Evidence

The finite head consumer follows an infinite producer, and flash creation precedes both the image
overlay and QEMU launch. The existing HiSilicon smoke test uses dd rather than a truncated
producer pipeline.

.github/workflows/build-xm.yml[208-225]
.github/workflows/build-hisilicon.yml[290-300]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The infinite `tr` producer receives SIGPIPE when `head` has written 8 MiB, making the smoke step fail before booting QEMU.
## Fix Focus Areas
- .github/workflows/build-xm.yml[213-215]
## Recommended Fix
Create an exactly 8 MiB erased flash file without an infinite-producer pipeline that fails under `pipefail`, then retain the U-Boot image overlay.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

check_kind divides the image’s byte count by 1024 before comparing it with the 256 KiB partition
limit, discarding any remainder. An image between 262,145 and 263,167 bytes therefore passes the
check despite extending beyond the boot partition into the environment area.

Code

.github/workflows/build-xm.yml[R115-117]

+              size_kb=$(( $(stat -c %s "$f") / 1024 ))
+              echo "- $f: [${size_kb}KB/${limit_kb}KB]"
+              if [ "$size_kb" -gt "$limit_kb" ]; then

Evidence

The workflow states that NOR boot ends at 256 KiB, but integer division makes every image from one
to 1,023 bytes above that boundary compare as 256 KiB.

.github/workflows/build-xm.yml[98-124]
CLAUDE.md[75-79]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Rounding image sizes down to whole KiB lets slightly oversized NOR images pass the partition-fit gate.
## Fix Focus Areas
- .github/workflows/build-xm.yml[107-120]
## Recommended Fix
Compare the raw `stat` byte count against `limit_kb * 1024`; round only values displayed in diagnostic messages.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

💡 Did you know, you can see how risky a PR is at a glance with blast radius labels

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗